Functional specification
########################

; * Scope and design principles
;   * Self-sufficient
;   * Cover everything needed to host Genode
;   * Convenience functions accepted only if the Genode base system benefits
;     from them
;   * No application-level API (for example, string functions must not be
;     misunderstood as string API)
; * Mention roles of base and os repositories
; * Check for headers that contain no classes
; * Naming convention
;   * colors (blue: class; yellow: namespace; green: method)
;   * global function, class function, object methods
;   * accessor
;   * typedef vs. sub type


API primitives
==============

Capability types
~~~~~~~~~~~~~~~~

As described in Section [Capability-based security], inter-component
communication is based on capabilities.
A capability refers to a system-wide unique object identity and can
be delegated among components.
At API level, each capability is associated with the type of the RPC
interface the capability refers to - similar to how a C++ reference refers to
the type of a specific C++ object.

;; internal
;; Genode::Native_capability_tpl<>

; XXX Genode::Capability<>

[raw spec/classes/genode/capability/description]

; XXX typed capabilities
; XXX lifetime of capabilities: mention ref counter


[raw spec/clearpage]

Sessions and connections
~~~~~~~~~~~~~~~~~~~~~~~~

Servers provide their services over session-based communication channels.
A Session type is defined as an abstract interface inherited from the
'Session' base class.

; Genode::Session
[raw spec/classes/genode/session/description]

Each session interface has to provide an implementation of the following
class function that returns the name of the service as constant string.

! static const char *service_name();

This function is used by the framework for the announcement of the
service's root interface at the component's parent. The string returned
by this function corresponds to the service name as used in the
system configuration (Section [System configuration]).

The interaction of a client with a server involves the definition of
session-construction arguments, the request of the session creation
via its parent, the initialization of the matching RPC-client stub
code with the received session capability, the actual use of the
session interface, and the closure of the session.
The 'Connection' template class provides a way to greatly simplify the
handling of session arguments, session creation, and destruction
on the client side. By implementing a service-specific connection
class inherited from 'Connection', session arguments become plain
constructor arguments, session functions can be called directly
on the 'Connection' object, and the session gets properly closed
when destructing the 'Connection'.

; XXX Genode::Connection<>
[raw spec/classes/genode/connection/description]


[raw spec/clearpage]

Dataspace interface
~~~~~~~~~~~~~~~~~~~

The dataspace abstraction described in Section [Dataspace] is the
fundamental API primitive for representing a container of memory as
provided by core's RAM, IO_MEM, or ROM services. Each dataspace is referenced
by a capability that can be passed among components.
Each component with the capability to a dataspace can access the
dataspace's content by attaching the dataspace to its RM session.
In addition to be used as arguments for RM-session calls,
dataspaces provide the following interface.

; XXX Genode::Dataspace_client

; Genode::Dataspace
[raw spec/classes/genode/dataspace/description]

; XXX Genode::Attached_dataspace


Component execution environment
===============================


Interface to the component's environment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As described in Section [Component creation],
each component is a composition of a protection domain (PD session), a
memory budget (RAM session), an address-space layout (RM session),
and a CPU session, from which the main thread is created. These
sessions form the _environment_ of the process, which is represented
by the 'Env' class.
In addition to the component's initial sessions, the environment
contains the heap of the component. The heap can be used for
anonymous memory allocation and is the front end for allocating
RAM dataspaces from the component's RAM session and attaching
these dataspaces to the component's RM session. The component's
environment can be accessed via the global 'env()' function:

[raw spec/repos/base/include/base/env.h.overview]

The interface returned by the 'env()' function looks as follows:

; Genode::Env
[raw spec/classes/genode/env/description]


By default, the component environment holds one initial LOG session
used as the standard text-output facility. For debugging purposes,
there exists a 'printf' front end for writing text to the initial
LOG session.

; base: printf
[raw spec/repos/base/include/base/printf.h.overview]


[raw spec/clearpage]

Parent interface
~~~~~~~~~~~~~~~~

At its creation time, the only communication partner of a component
is its immediate parent. The parent can be reached via interface returned
by 'env()->parent()'.

; XXX Genode::Parent_client

; Genode::Parent
[raw spec/classes/genode/parent/description]


[raw spec/clearpage]

Component-configuration interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

; XXX Genode::Config


Session interfaces of the base API
==================================

RAM session interface
~~~~~~~~~~~~~~~~~~~~~

The RAM service (Section [Physical memory allocation (RAM)]) provides
access to physical memory. Each RAM
session corresponds to a memory budget with a bounded quota. From this
budget, the RAM-session client can allocate memory blocks in the form
of dataspaces.

; XXX Genode::Ram_session_client

; Genode::Ram_dataspace
[raw spec/repos/base/include/ram_session/ram_session.h.overview]

; Genode::Ram_session
[raw spec/classes/genode/ram_session/description]

; Genode::Ram_connection
[raw spec/classes/genode/ram_connection/description]

; XXX Genode::Attached_ram_dataspace


[raw spec/clearpage]

ROM session interface
~~~~~~~~~~~~~~~~~~~~~

The ROM service (Section [Read-only memory (ROM)]) provides access to
ROM modules, e.g., binary data loaded by the boot loader
(core's ROM service described in Section [Access to boot modules (ROM)]).
Each session refers to one ROM module. The module's data is provided to
the client in the form of a dataspace (Section [Dataspaces]).

; Genode::Rom_dataspace
[raw spec/repos/base/include/rom_session/rom_session.h.overview]

; Genode::Rom_session
[raw spec/classes/genode/rom_session/description]

; XXX Genode::Rom_session_client

; Genode::Rom_connection
[raw spec/classes/genode/rom_connection/description]

; XXX Genode::Attached_rom_dataspace


[raw spec/clearpage]

PD session interface
~~~~~~~~~~~~~~~~~~~~

The protection-domain (PD) service (Section [Protection domains (PD)]) enables
the creation of address spaces that are isolated from each other. Each PD
session corresponds to a protection domain. The PD service is rarely
needed by applications directly but it is internally used by the
child-management facilities described in Section [Child management].

; XXX Genode::Pd_session_client

; Genode::Pd_session
[raw spec/classes/genode/pd_session/description]

; Genode::Pd_connection
[raw spec/classes/genode/pd_connection/description]


[raw spec/clearpage]

RM session interface
~~~~~~~~~~~~~~~~~~~~

The region-manager (RM) service (Section [Address-space management (RM)])
manages address-space layouts. An RM session corresponds to an address-space
layout, to which dataspaces can be attached.

; XXX Genode::Rm_session_client

; Genode::Rm_session
[raw spec/classes/genode/rm_session/description]

; Genode::Rm_connection
[raw spec/classes/genode/rm_connection/description]


[raw spec/clearpage]

CPU session interface
~~~~~~~~~~~~~~~~~~~~~

The CPU service (Section [Processing-time allocation (CPU)]) provides a
facility for creating and managing threads. A CPU session corresponds to a
CPU-time allocator, from which multiple threads can be allocated.
;
; XXX Genode::Thread_state
; XXX Genode::Thread_state_base
;
; XXX Genode::Cpu_session_client

; Genode::Cpu_session
[raw spec/classes/genode/cpu_session/description]

; Genode::Cpu_connection
[raw spec/classes/genode/cpu_connection/description]

; Genode::Affinity
[raw spec/classes/genode/affinity/description]


[raw spec/clearpage]

CAP session interface
~~~~~~~~~~~~~~~~~~~~~

The capability (CAP) service (Section [Object-identity allocation (CAP)])
enables the creation of globally unique object identities (capabilities).
Once allocated from a CAP session, a capability can be associated with a local
object. A capability can be passed to another protection domain via an RPC
call whereby the receiving protection domain obtains the right to send
messages to the associated object.

; XXX Genode::Cap_session_client

; Genode::Cap_session
[raw spec/classes/genode/cap_session/description]

; Genode::Cap_connection
[raw spec/classes/genode/cap_connection/description]


[raw spec/clearpage]

IO_MEM session interface
~~~~~~~~~~~~~~~~~~~~~~~~

The IO_MEM service
(Section [Access to device resources (IO_MEM, IO_PORT, IRQ)])
enables user-level device drivers to
obtain memory-mapped device resources in the form of dataspaces. Each
IO_MEM session corresponds to the reservation of a physical
address range, for which a dataspace is provided to the client.
The user-level device driver can make the device resource
visible in its address space by attaching the dataspace to
its own RM session.

; XXX Genode::Io_mem_session_client

; XXX Genode::Io_mem_dataspace
[raw spec/repos/base/include/io_mem_session/io_mem_session.h.overview]

; Genode::Io_mem_session
[raw spec/classes/genode/io_mem_session/description]

; Genode::Io_mem_connection
[raw spec/classes/genode/io_mem_connection/description]

; XXX Genode::Attached_io_mem_dataspace


[raw spec/clearpage]

IO_PORT session interface
~~~~~~~~~~~~~~~~~~~~~~~~~

On the x86 architecture, the IO_PORT service
(Section [Access to device resources (IO_MEM, IO_PORT, IRQ)])
provides access to device I/O ports via an RPC interface. Each IO_PORT session
corresponds to the access right to a port range.

; XXX Genode::Io_port_session_client

; Genode::Io_port_session
[raw spec/classes/genode/io_port_session/description]

; Genode::Io_port_connection
[raw spec/classes/genode/io_port_connection/description]


[raw spec/clearpage]

IRQ session interface
~~~~~~~~~~~~~~~~~~~~~

The IRQ service
(Section [Access to device resources (IO_MEM, IO_PORT, IRQ)])
enables user-level device drivers to serve device interrupts. Each IRQ session
corresponds to an associated interrupt line.

; XXX Genode::Irq_session_client
; XXX Genode::Irq_handler
; XXX Genode::Irq_activation

; XXX Genode::Irq_session
;[raw spec/classes/genode/irq_session/description]

; Genode::Irq_connection
[raw spec/classes/genode/irq_connection/description]



[raw spec/clearpage]

LOG session interface
~~~~~~~~~~~~~~~~~~~~~

For low-level debugging, core provides a simple LOG service
(Section [Logging (LOG)]), which
enables clients to print textual messages. In the LOG output,
each message is tagged with the label of the corresponding client.

; XXX Genode::Log_session_client

; Genode::Log_session
[raw spec/classes/genode/log_session/description]

; Genode::Log_connection
[raw spec/classes/genode/log_connection/description]


[raw spec/clearpage]

SIGNAL session interface
~~~~~~~~~~~~~~~~~~~~~~~~

The SIGNAL service (Section [Asynchronous notifications (SIGNAL)])
is used for the allocation of signal contexts and the delivery of signals.
It is not used directly by
components at the API level but used indirectly via the signalling API
described in Section [Signalling].

; XXX Genode::Signal_session_client
; XXX Genode::Signal_source
; XXX Genode::Signal_source_client
; XXX Genode::Signal_session
; XXX Genode::Signal_source_rpc_object
; XXX Genode::Signal_connection


;TRACE session interface
;~~~~~~~~~~~~~~~~~~~~~~~
;
;; Genode::Trace::Policy_module
;; Genode::Trace::Buffer
;; Genode::Trace::Policy_id
;; Genode::Trace::Subject_id
;; Genode::Trace::Subject_info
;; Genode::Trace::Logger
;; Genode::Trace::Rpc_call
;; Genode::Trace::Rpc_returned
;; Genode::Trace::Rpc_dispatch
;; Genode::Trace::Rpc_reply
;; Genode::Trace::Signal_submit
;; Genode::Trace::Signal_received
;; Genode::Trace::Session_client
;; Genode::Trace::Session
;; Genode::Trace::Connection


OS-level session interfaces
===========================

Report session interface
~~~~~~~~~~~~~~~~~~~~~~~~

; XXX Genode::Reporter
; XXX Report::Session_client
; XXX Report::Connection
; XXX Report::Session


Terminal session interface
~~~~~~~~~~~~~~~~~~~~~~~~~~

; XXX Terminal::Session_client
; XXX Terminal::Connection
; XXX Terminal::Session


UART session interface
~~~~~~~~~~~~~~~~~~~~~~

; XXX Uart::Session_client
; XXX Uart::Session
; XXX Uart::Connection


Input session interface
~~~~~~~~~~~~~~~~~~~~~~~

; XXX Input::Session
; XXX Input::Session_client
; XXX Input::Connection


Framebuffer session interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

; XXX Framebuffer::Session_client
; XXX Framebuffer::Connection
; XXX Framebuffer::Mode
; XXX Framebuffer::Session


Nitpicker session interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~

; XXX Nitpicker::Session
; XXX Nitpicker::Session_client
; XXX Nitpicker::Connection


PCI session interface
~~~~~~~~~~~~~~~~~~~~~

; XXX Pci::Device_client
; XXX Pci::Device
; XXX Pci::Session_client
; XXX Pci::Session
; XXX Pci::Connection


Block session interface
~~~~~~~~~~~~~~~~~~~~~~~

; XXX Block::Session_client
; XXX Block::Packet_descriptor
; XXX Block::Session
; XXX Block::Session_rpc_object
; XXX Block::Connection


Regulator session interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~

; XXX Regulator::Session_client
; XXX Regulator::Session_rpc_object
; XXX Regulator::Session
; XXX Regulator::Connection


Timer session interface
~~~~~~~~~~~~~~~~~~~~~~~

; XXX Timer::Session_client
; XXX Timer::Session
; XXX Timer::Connection


NIC session interface
~~~~~~~~~~~~~~~~~~~~~

; XXX Nic::Session_client
; XXX Nic::Mac_address
; XXX Nic::Session
; XXX Nic::Session_rpc_object
; XXX Nic::Connection


Audio-out session interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~

; XXX Audio_out::Signal
; XXX Audio_out::Session_client
; XXX Audio_out::Packet
; XXX Audio_out::Stream
; XXX Audio_out::Session
; XXX Audio_out::Session_rpc_object
; XXX Audio_out::Connection


File-system session interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

; XXX File_system::Session_client
; XXX File_system::Node_handle
; XXX File_system::File_handle
; XXX File_system::Dir_handle
; XXX File_system::Symlink_handle
; XXX File_system::Packet_descriptor
; XXX File_system::Status
; XXX File_system::Control
; XXX File_system::Directory_entry
; XXX File_system::Session
; XXX File_system::Session_rpc_object
; XXX File_system::Connection


Loader session interface
~~~~~~~~~~~~~~~~~~~~~~~~

; XXX Loader::Session_client
; XXX Loader::Connection
; XXX Loader::Session


;GPIO session interface
;~~~~~~~~~~~~~~~~~~~~~~
;
;; Gpio::Session_client
;; Gpio::Connection
;; Gpio::Session


;USB session interface
;~~~~~~~~~~~~~~~~~~~~~
;
;; Usb::Session_client
;; Usb::Packet_descriptor
;; Usb::Completion
;; Usb::Session
;; Usb::Session_rpc_object
;; Usb::Connection


;RTC session interface
;~~~~~~~~~~~~~~~~~~~~~
;
;; Rtc::Session_client
;; Rtc::Connection
;; Rtc::Timestamp
;; Rtc::Session


Fundamental types
=================

Integer types
~~~~~~~~~~~~~

Genode provides common integer types in its namespace.
Integer types that can be derived from built-in compiler
types are defined in _base/stdint.h_ and _base/fixed_stdint.h_.
Whereas the former is independent from the machine type, the latter
differs between 32-bit and 64-bit architectures.

[raw spec/repos/base/include/base/stdint.h.overview]

[raw spec/clearpage]
The fixed-width integer types for 32-bit architectures are defined
as follows.

[raw spec/repos/base/include/32bit/base/fixed_stdint.h.overview]

[raw spec/clearpage]
The fixed-width integer types for 64-bit architectures are defined
as follows.

[raw spec/repos/base/include/64bit/base/fixed_stdint.h.overview]


Exception types
~~~~~~~~~~~~~~~

Genode facilitates the use of exceptions to signal errors but it
uses exception types only as textual expression of error code and
for grouping errors. Normally, exceptions do not carry payload.
For code consistency, exception types should inherit from the
'Exception' base class. By convention, exceptions carry no payload.

; Genode::Exception
[raw spec/classes/genode/exception/description]


C++ supplements
~~~~~~~~~~~~~~~

; Genode::Noncopyable
[raw spec/classes/genode/noncopyable/description]


Data structures
===============

The framework API features a small library of data structures that are
solely exist to support the framework implementation. They have been
designed under the following considerations:

* They should be *as simple as possible* to make them easy to evaluate for
  correctness. Low complexity takes precedence over performance.

* Each data structure provides a *rigid interface* that is targeted at a
  specific use case and does not attempt to be a power tool. For example,
  the 'Fifo' deliberately provides no way to randomly access
  elements, the 'List' merely provides the functionality to remember
  elements but lacks list-manipulation operations.

* Data structures perform no hidden anonymous memory allocations by
  *storing meta data intrusively*. This is precondition for allowing
  resources multiplexers and runtime environments to properly account their
  local memory allocations. Section [Component-local heap partitioning]
  provides the rationale behind the need for full control over memory
  allocations.


[raw spec/clearpage]

List
~~~~

Most book-keeping tasks in Genode rely on single-connected lists,
which use the 'List' template.

; Genode::List<>
[raw spec/classes/genode/list/description]

; Genode::List_element<>
[raw spec/classes/genode/list_element/description]


[raw spec/clearpage]

Fifo queue
~~~~~~~~~~

Because the 'List' inserts new list elements at the
list head, it cannot be used for implementing wait queues requiring
first-in-first-out semantics. For such use cases, there exists a
dedicated 'Fifo' template.

; Genode::Fifo<>
[raw spec/classes/genode/fifo/description]

; Genode::Fifo_element<>
[raw spec/classes/genode/fifo_element/description]


[raw spec/clearpage]

AVL tree
~~~~~~~~

For use cases where associative arrays are needed such as allocators, there
is class template for creating AVL trees. The tree-balancing mechanism
is implemented in the 'Avl_node_base' class. The actual 'Avl_node' and
'Avl_tree' classes are tagged with the element type, which ensures that each
AVL tree hosts only one type of elements.

; Genode::Avl_node_base
[raw spec/classes/genode/avl_node_base/description]

; Genode::Avl_node<>
[raw spec/classes/genode/avl_node/description]

; Genode::Avl_tree<>
[raw spec/classes/genode/avl_tree/description]

;XXX is this really interesting for the API?
;To accommodate the common use case for using strings as keys into an
;dictionary, there exists a specialized version of the AVL tree for managing
;pools of strings.
;; Genode::Avl_string_base
;[raw spec/classes/genode/avl_string_base/description]
;
;; Genode::Avl_string<>
;[raw spec/classes/genode/avl_string/description]


[raw spec/clearpage]

Bit array
~~~~~~~~~

Bit arrays are typically used for the allocation of IDs. The 'Bit_array_base'
class operates on a memory buffer specified to its constructor. The
'Bit_array' class template addresses the common case where the ID space
is dimensioned at compile time. It takes the number of bits as arguments
and hosts the memory buffer for storing the bits within the object.

; Genode::Bit_array_base
[raw spec/classes/genode/bit_array_base/description]

; Genode::Bit_array<>
[raw spec/classes/genode/bit_array/description]


[raw spec/clearpage]

Ring buffer
~~~~~~~~~~~

; Genode::Ring_buffer_unsynchronized
; Genode::Ring_buffer_synchronized
; Genode::Ring_buffer<>


;Handle registry
;~~~~~~~~~~~~~~~
;
;; Genode::Handle<>
;; Genode::Handle_registry<>


;Geometry
;~~~~~~~~
;
;; Genode::Point<>
;; Genode::Area<>
;; Genode::Rect<>
;; Genode::Dirty_rect<>
;
;;; Genode::Flexpage
;;; Genode::Flexpage_iterator


Object lifetime management
==========================

Thread-safe weak pointers
~~~~~~~~~~~~~~~~~~~~~~~~~

Dangling pointers represent one of the most common cause for instabilities
of software written in C or C++. Such a
situation happens when an object disappears while pointers to the object
are still in use. One way to solve this problem is to explicitly notify the
holders of those pointers about the disappearance of the object. But this
would require the object to keep references to those pointer holders, which,
in turn, might disappear as well. Consequently, this approach tends to
become a complex solution, which is prone to deadlocks or race conditions
when multiple threads are involved.

The utilities provided by _base/weak_ptr.h_ implement a more elegant pattern
called "weak pointers" to deal with such situations. An object that might
disappear at any time is represented by the 'Weak_object' class
template. It keeps track of a list of so-called weak pointers pointing
to the object. A weak pointer, in turn, holds privately the pointer to the
object alongside a validity flag. It cannot be used to dereference the
object. For accessing the actual object, a locked pointer must be created
from a weak pointer. If this creation succeeds, the object is guaranteed to
be locked (not destructed) until the locked pointer gets destroyed. If the
object no longer exists, the locked pointer will become invalid. This condition
can (and should) be detected via the 'Locked_ptr::is_valid()' function prior
dereferencing the pointer.

In the event a weak object gets destructed, all weak pointers that point
to the object are automatically invalidated. So a subsequent conversion into
a locked pointer will yield an invalid pointer, which can be detected (in
contrast to a dangling pointer).

To use this mechanism, the destruction of a weak object must be
deferred until no locked pointer points to the object anymore. This is
done by calling the function 'Weak_object::lock_for_destruction()'
at the beginning of the destructor of the to-be-destructed object.
When this function returns, all weak pointers to the object will have been
invalidated. So it is save to destruct and free the object.

; Genode::Weak_object_base
[raw spec/classes/genode/weak_object_base/description]

; Genode::Weak_object<>
[raw spec/classes/genode/weak_object/description]

; Genode::Weak_ptr_base
[raw spec/classes/genode/weak_ptr_base/description]

; Genode::Weak_ptr<>
[raw spec/classes/genode/weak_ptr/description]

; Genode::Locked_ptr_base
[raw spec/classes/genode/locked_ptr_base/description]

; Genode::Locked_ptr<>
[raw spec/classes/genode/locked_ptr/description]


[raw spec/clearpage]

Volatile objects
~~~~~~~~~~~~~~~~

; XXX description

; construct_at
[raw spec/repos/base/include/util/construct_at.h.overview]

; XXX Genode::Volatile_object<>
;[raw spec/classes/genode/volatile_object/description]

; XXX Genode::Lazy_volatile_object<>
;[raw spec/classes/genode/lazy_volatile_object/description]



Allocators
==========

All allocators implement the generic 'Deallocator' and 'Allocator' interfaces.
Allocators that operate on address ranges supplement the plain 'Allocator'
by implementing the more specific 'Range_allocator' interface.

; Genode::Deallocator
[raw spec/classes/genode/deallocator/description]

; Genode::Allocator
[raw spec/classes/genode/allocator/description]

; Genode::Range_allocator
[raw spec/classes/genode/range_allocator/description]


[raw spec/clearpage]

Allocator guard
~~~~~~~~~~~~~~~

To protect the quantum of allocated memory from exceeding a predefined limit,
an allocator guard can be used. It is typically used by server implementations
that subdivide their heap into client-specific partitions dimensioned
according to the session quota provided by the respective client.

; Genode::Allocator_guard
[raw spec/classes/genode/allocator_guard/description]


[raw spec/clearpage]

Slab allocator
~~~~~~~~~~~~~~

The 'Slab' allocator is tailored for allocating small fixed-size
memory blocks from a big chunk of memory.
For the common use case of using a slab allocator for a certain
type rather than for a known byte size, there exists a typed
slab allocator as a front end of 'Slab'.

; XXX should be hidden
; Genode::Slab_block
; Genode::Slab_entry

; Genode::Slab
[raw spec/classes/genode/slab/description]

; Genode::Tslab<>
[raw spec/classes/genode/tslab/description]


[raw spec/clearpage]

AVL-tree-based best-fit allocator
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In contrast to the rather limited slab allocators, 'Allocator_avl'
allows for arbitrary allocations from a list of address regions.
It implements a best-fit allocation strategy, supports arbitrary
alignments, and allocations at specified addresses.

; Genode::Allocator_avl_base
[raw spec/classes/genode/allocator_avl_base/description]

; Genode::Allocator_avl_tpl<>
[raw spec/classes/genode/allocator_avl_tpl/description]


[raw spec/clearpage]

Heap and sliced heap
~~~~~~~~~~~~~~~~~~~~

; Genode::Heap
[raw spec/classes/genode/heap/description]

; Genode::Sliced_heap
[raw spec/classes/genode/sliced_heap/description]


[raw spec/clearpage]

Bit allocator
~~~~~~~~~~~~~

; Genode::Bit_allocator<>
[raw spec/classes/genode/bit_allocator/description]

; XXX should be removed
;; Genode::Synchronized_allocator<>
;; Genode::Synchronized_range_allocator<>


String processing
=================

; explain that this is no application-level string API


Basic string operations
~~~~~~~~~~~~~~~~~~~~~~~

There exists a small set of string-manipulation operations as global functions
in the 'Genode' namespace.

[raw spec/repos/base/include/util/string.h.overview]

; XXX ascii_to
; XXX Genode::Number_of_bytes
;[raw spec/classes/genode/number_of_bytes/description]

[raw spec/clearpage]
To cover the common case of embedding a string buffer as a member variable in
a class, there exists the 'String' class template, which alleviates the
need for C-style arrays in such situations.

; Genode::String<>
[raw spec/classes/genode/string/description]


[raw spec/clearpage]

Tokenizing
~~~~~~~~~~

For parsing structured text such as argument strings or XML,
simple tokenizing support is provided via the 'Token' class.

; Genode::Token<>
[raw spec/classes/genode/token/description]

; XXX Genode::Scanner_policy_identifier_with_underline


[raw spec/clearpage]

Format strings
~~~~~~~~~~~~~~

Format strings are commonly used for printing debug output. Throughout Genode,
only a small subset of format-string features are needed. The processing of
such simple format strings is performed by the low-complexity 'Console'
utility. For the subset of supported formatting commands, please refer to the
implementation at _repos/base/src/base/console/console.cc_. The 'Console'
has a protected pure virtual '_out_char' function that needs to be implemented
by a derived class.

; Genode::Console
[raw spec/classes/genode/console/description]

The 'String_console' implements the 'Console' interface by writing the output
to memory. It thereby allows the rendering of format strings into character
buffers.

; Genode::String_console
[raw spec/classes/genode/string_console/description]

There exists a convenient wrapper for the 'String_console' in the form of the
'snprintf' function.

[raw spec/repos/base/include/base/snprintf.h.overview]


[raw spec/clearpage]

String-argument parsing
~~~~~~~~~~~~~~~~~~~~~~~

The 'Arg_string' utility is able to extract individual values from
strings of comma-separated 'tag=value' sequences.

; Genode::Arg
[raw spec/classes/genode/arg/description]

; Genode::Arg_string
[raw spec/classes/genode/arg_string/description]


;; not important
;
;Alarm scheduling
;================
;
;; Genode::Alarm
;; Genode::Alarm_scheduler


Multi-threading and synchronization
===================================

; XXX information about thread-context management (as given in base/thread.h)


Threads
~~~~~~~

A thread is created by constructing an object of a class inherited from
'Thread_base'. The new thread starts its execution at the 'entry' member
function.
Thereby, each thread runs in the context of its object and
can access context-specific information by accessing its member
variables. This largely alleviates the need for a thread-local storage (TLS)
mechanism.
Threads use a statically allocated stack, which is dimensioned according
to the corresponding constructor argument.

; Genode::Thread_base
[raw spec/classes/genode/thread_base/description]


[raw spec/clearpage]

The 'Thread' class template accommodates the common case of creating
threads with their stack size known at compile time. It takes the
stack size as template argument.

; Genode::Thread<>
[raw spec/classes/genode/thread/description]


[raw spec/clearpage]

Blocking operations performed by threads can be canceled via the
thread's 'cancel_blocking' method. The cancellation of a blocking
operation is reflected at the API level by a raised exception of the type
'Blocking_canceled'.

; Genode::Blocking_canceled
[raw spec/repos/base/include/base/blocking.h.overview]


[raw spec/clearpage]


Locks and semaphores
~~~~~~~~~~~~~~~~~~~~

For mutual exclusive execution of critical sections, there exists
a simple lock interface providing lock and unlock semantics.
The lock comes in two flavours. Cancelable locks can be
unblocked by force via core's cancel-blocking mechanism. In contrast,
a non-cancelable lock ('Lock') does not reflect the cancellation of
its blocking operation at the API level but transparently re-enters
its blocking state after a cancellation.

; Genode::Cancelable_lock
[raw spec/classes/genode/cancelable_lock/description]

; Genode::Lock
[raw spec/classes/genode/lock/description]

For the use case of using locks for protecting critical sections,
the 'Lock_guard' provides a convenient mechanism for the automated
unlocking of a lock when leaving a variable scope.

; Genode::Lock_guard<>
[raw spec/classes/genode/lock_guard/description]


[raw spec/clearpage]

Alongside lock-based mutual exclusion of entering critical sections,
organizing threads in a producer-consumer relationship is a common
design pattern for thread synchronization. The 'Semaphore' interface
enables the implementation of this synchronization scheme.

; Genode::Semaphore
[raw spec/classes/genode/semaphore/description]


[raw spec/clearpage]

To synchronize method calls of an object, the 'Synced_interface' can be
used to equip the class of the called object with thread safety.

; XXX Genode::Synced_interface<>
;[raw spec/classes/genode/synced_interface/description]

; Page-fault handling should become private
;; Genode::Pager_object
;; Genode::Pager_activation_base
;; Genode::Pager_entrypoint
;; Genode::Pager_activation<>

; Timed semaphore should not be promoted
;
; Genode::Timeout_thread
; Genode::Timeout_exception
; Genode::Nonblocking_exception
; Genode::Timed_semaphore


Signalling
==========

Section [Asynchronous notifications (SIGNAL)] provides the high-level
description of the mechanism for the delivery of asynchronous notifications
(signals).
The API defines interfaces for signal transmitters and signal
receivers. A signal receiver can receive signals from multiple sources
each source represented by a signal context.
Signal contexts make incoming signals are distinguishable. One or
multiple threads can either poll or block for incoming signals.
Each signal receiver is addressable via its associated signal
context capabilities.
The signal transmitter provides fire-and-forget semantics for submitting
signals to one signal receiver.
Signals serve as raw notifications and cannot carry any payload.

; Genode::Signal
[raw spec/classes/genode/signal/description]

; Genode::Signal_context
[raw spec/classes/genode/signal_context/description]

; Genode::Signal_receiver
[raw spec/classes/genode/signal_receiver/description]

; Genode::Signal_transmitter
[raw spec/classes/genode/signal_transmitter/description]

; XXX Genode::Signal_dispatcher_base
; XXX Genode::Signal_rpc_dispatcher_base
; XXX Genode::Signal_dispatcher<>
; XXX Genode::Signal_rpc_functor<>
; XXX Genode::Signal_rpc_member<>


Remote procedure calls
======================

Section [Synchronous remote procedure calls (RPC)] provides the high-level
description of synchronous remote procedure calls.


RPC mechanism
~~~~~~~~~~~~~

The RPC mechanism consists of the following header files:

:_base/rpc.h_:
  Contains the basic type definitions and utility macros to declare RPC
  interfaces.

:'base/rpc_args.h':
  Contains definitions of non-trivial argument types used for transferring
  strings and binary buffers. Its use by RPC interfaces is optional.

:'base/rpc_server.h':
  Contains the interfaces of the server-side RPC API. This part of the API
  consists of the 'Rpc_object' class template and the 'Rpc_entrypoint' class.

:'base/rpc_client.h':
  Contains the API support for invoking RPC functions. It is complemented by
  the definitions in _base/capability.h_. The most important elements of the
  client-side RPC API are the 'Capability' class template and 'Rpc_client',
  which is a convenience wrapper around 'Capability'.

Each RPC interface is an abstract C++ interface, supplemented by a few
annotations. For example:

! #include <session/session.h>
! #include <base/rpc.h>
!
! namespace Hello {
!
!   struct Session : public Genode::Session
!   {
!       static const char *service_name() { return "Hello"; }
!
!       virtual void say_hello() = 0;
!       virtual int add(int a, int b) = 0;
!
!       GENODE_RPC(Rpc_say_hello, void, say_hello);
!       GENODE_RPC(Rpc_add, int, add, int, int);
!       GENODE_RPC_INTERFACE(Rpc_say_hello, Rpc_add);
!   };
! }

The macros 'GENODE_RPC' and 'GENODE_RPC_INTERFACE' are defined in _base/rpc.h_
and enrich the interface with type information. They are only used at compile
time and have no effect on the run time or the size of the class.
Each RPC function is represented as a type. In the example, the type meta
data of the 'say_hello' function is attached to the 'Rpc_say_hello' type
within the scope of 'Session'. The macro arguments are:

! GENODE_RPC(func_type, ret_type, func_name, arg_type ...)

The 'func_type' argument is an arbitrary type name (except for the type name
'Rpc_functions') used to refer to the RPC function, 'ret_type' is the return
type or 'void', 'func_name' is the name of the server-side function that
implements the RPC function, and the list of 'arg_type' arguments comprises the
RPC function argument types. The 'GENODE_RPC_INTERFACE' macro defines a type
called 'Rpc_functions' that contains the list of the RPC functions provided by
the RPC interface.


Server side
-----------

The implementation of the RPC interface inherits the 'Rpc_object' class
template with the interface type as argument and implements the abstract
RPC interface class.

;The server-side RPC dispatching is performed by the compile-time-generated
'dispatch' method of the 'Rpc_object' class template, according to the type
information found in the annotations of the 'Session' interface.

; Genode::Rpc_object_base
[raw spec/classes/genode/rpc_object_base/description]

; XXX Genode::Rpc_object<>
; XXX Genode::Rpc_dispatcher<>
;[raw spec/classes/genode/rpc_object/description]


To make an instance of an RPC object invokable via RPC, it must be associated
with an RPC entrypoint. By passing an RPC object to the 'manage' function of
an RPC entrpoint, a new capability for the RPC object is created. The
capability tagged with the type of the RPC object.

; Genode::Rpc_entrypoint
[raw spec/classes/genode/rpc_entrypoint/description]


Client side
-----------

At the client side, a capability can be invoked by the capability's 'call'
method template with the RPC functions type as template argument. The
method arguments correspond to the RPC function arguments.

By convention, the 'Capability::call' method is rarely used directly.
Instead, each RPC interface is accompanied with a client-side implementation
of the abstract interface where each RPC function is implemented by calling
the 'Capability::call' method. This convention is facilitated by the
'Rpc_client' class template.

; Genode::Rpc_client
[raw spec/classes/genode/rpc_client/description]

Using this template, the client-side implementation of the example RPC
interface looks as follows.

! #include <hello_session/hello_session.h>
! #include <base/rpc_client.h>
! #include <base/printf.h>
!
! namespace Hello {
!
!   struct Session_client : Genode::Rpc_client<Session>
!   {
!     Session_client(Genode::Capability<Session> cap)
!     : Genode::Rpc_client<Session>(cap) { }
!
!     void say_hello()
!     {
!       call<Rpc_say_hello>();
!     }
!
!     int add(int a, int b)
!     {
!       return call<Rpc_add>(a, b);
!     }
!   };
! }

For passing RPC arguments and results, the regular C++ type-conversion rules
are in effect. If there is no valid type conversion, or if the number of
arguments is wrong, or if the RPC type annotations are not consistent with the
abstract interface, the error is detected at compile time.


Transferable argument types
~~~~~~~~~~~~~~~~~~~~~~~~~~~

The arguments specified to 'GENODE_RPC' behave mostly as expected for a normal
function call. But there are some notable differences:

:Value types:
  Value types are supported for basic types and plain-old-data types
  (self-sufficient structs or classes). The object data is transferred as such.
  If the type is not self-sufficient (it contains pointers or references), the
  pointers and references are transferred as plain data, most likely
  pointing to the wrong thing in the callee's address space.

:Const references:
  Const references behave like value types. The referenced object is
  transferred to the server and a reference to the server-local copy is passed
  to the server-side function. Note that in contrast to a normal function
  call that takes a reference argument, the size of the referenced object is
  accounted for allocating the message buffer on the client side.

:Non-const references:
  Non-const references are handled similar to const references. In addition the
  server-local copy gets transferred back to the caller so that server-side
  modifications of the object become visible to the client.

:Capabilities:
  Capabilities can be transfered as values, const references, or non-const
  references.

:Variable-length buffers:
  There exists special support for passing binary buffers to RPC functions using
  the 'Rpc_in_buffer' class template provided by _base/rpc_args.h_. The maximum
  size of the buffer must be specified as template argument. An 'Rpc_in_buffer'
  object does not contain a copy of the data passed to the constructor, only a
  pointer to the data. In contrast to a fixed-sized object containing a copy of
  the payload, the RPC framework does not transfer the whole object but only
  the actually used payload.

:Pointers:
  Pointers and const pointers are handled similar to references. The pointed-to
  argument gets transferred and the server-side function is called with a
  pointer to the local copy.

All types specified at RPC arguments or as return value must have a default
constructor.

By default, all RPC arguments are input arguments, which are transferred to the
server. The return type of the RPC function, if present, is an output-only
value. To avoid a reference argument from acting as both input- and output
argument, a const reference should be used.


Throwing C++ exceptions across RPC boundaries
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The propagation of C++ exceptions from the server to the client is supported
by a special variant of the 'GENODE_RPC' macro:

! GENODE_RPC_THROW(func_type, ret_type, func_name,
!                  exc_type_list, arg_type ...)

This macro accepts an additional 'exc_type_list' argument, which is a type
list of exception types. Exception objects are not
transferred as payload. The RPC mechanism propagates solely the information
that the specific exception was raised. Hence, information provided with the
thrown object will be lost when crossing an RPC boundary.


RPC interface inheritance
~~~~~~~~~~~~~~~~~~~~~~~~~

It is possible to extend existing RPC interfaces with additional RPC
functions. Internally, such an RPC interface inheritance is realized by
concatenation of the 'Rpc_functions' type lists of both the base interface
and the derived interface. This use case is supported by a special version of
the 'GENODE_RPC_INTERFACE' macro:

! GENODE_RPC_INTERFACE_INHERIT(base_interface,
!                              rpc_func ...)


Casting capability types
~~~~~~~~~~~~~~~~~~~~~~~~

For typed capabilities, the same type conversion rules apply as for pointers.
In fact, a typed capability pretty much resembles a typed pointer, pointing
to a remote object. Hence, assigning a specialized capability (e.g.,
'Capability<Input::Session>') to a base-typed capability (e.g.,
'Capability<Session>') is always valid. For the opposite case, a static cast
is needed. For capabilities, this cast is supported by
! static_cap_cast<INTERFACE>(cap)

In rare circumstances, mostly in platform-specific base code, a reinterpret
cast for capabilities is required. It allows to convert any capability to
another type:
! reinterpret_cap_cast<INTERFACE>(cap)


Non-virtual RPC interface functions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It is possible to declare RPC functions using 'GENODE_RPC', which do not
exist as virtual functions in the abstract interface class. In this case, the
function name specified as third argument to 'GENODE_RPC' is of course not
valid for the interface class but an alternative class can be specified as
second argument to the server-side 'Rpc_object'. This way, a server-side
implementation may specify its own class to direct the RPC function to a local
(possibly non-virtual) implementation.


; XXX Genode::Rpc_in_buffer_base
; XXX Genode::Rpc_in_buffer<>


Limitations of the RPC mechanism
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The maximum *number of RPC function arguments* is limited to 7.
If a function requires more arguments, it may be worthwhile to consider
grouping some of them in a compound struct.

The maximum *number of RPC functions* per interface supported by the
'GENODE_RPC_INTERFACE' macro is limited to 9. In contrast to the limitation of
the number of function arguments, this limitation cannot be always avoided.
However, in cases like this, the limitation can be side-stepped by
manually constructing the type list of RPC functions instead of using the
convenience macro:
! typedef Meta::Type_tuple<Rpc_create_thread,
!         Meta::Type_tuple<Rpc_kill_thread,
!                          Meta::Empty> >
!         Rpc_functions;


[raw spec/clearpage]


Root interface
~~~~~~~~~~~~~~

Each service type is represented as an RPC object implementing
the root interface. The server announces its service type by
providing the service name and the capability of the service's root
interface ('announce' function of the parent interface).
Given the capability to the root interface, the parent is then able
to create and destroy sessions.

; Genode::Root
[raw spec/classes/genode/root/description]

; XXX Genode::Typed_root<>
; XXX Genode::Root_client

Because defining root interfaces for services follows a recurring pattern,
there exists default template classes that implement the standard behaviour of
the root interface for services with multiple clients ('Root_component') and
services with a single client ('Static_root').

; Genode::Root_component<>
[raw spec/classes/genode/root_component/description]

; XXX Genode::Single_client
; XXX Genode::Multiple_clients

; XXX Genode::Static_root<>
;[raw spec/classes/genode/static_root/description]


[raw spec/clearpage]

Server-side policy handling
~~~~~~~~~~~~~~~~~~~~~~~~~~~

; XXX Genode::Session_label
;[raw spec/classes/genode/session_label/description]

; XXX Genode::Session_policy
;[raw spec/classes/genode/session_policy/description]

; Should be preserved for internal use
;; Genode::Object_pool<>
;; Genode::Ipc_error
;; Genode::Ipc_marshaller
;; Genode::Ipc_unmarshaller
;; Genode::Ipc_ostream
;; Genode::Ipc_istream
;; Genode::Ipc_client
;; Genode::Ipc_server


Packet stream
~~~~~~~~~~~~~

; XXX Genode::Packet_allocator
; XXX Genode::Packet_descriptor
; XXX Genode::Packet_stream_base
; XXX Genode::Packet_descriptor_queue<>
; XXX Genode::Packet_descriptor_transmitter<>
; XXX Genode::Packet_descriptor_receiver<>
; XXX Genode::Packet_stream_source<>
; XXX Genode::Packet_stream_sink<>
; XXX Genode::Packet_stream_policy<>
; XXX Packet_stream_rx::Client<>
; XXX Packet_stream_rx::Rpc_object<>
; XXX Packet_stream_tx::Client<>
; XXX Packet_stream_tx::Rpc_object<>
; XXX Packet_stream_rx::Channel<>
; XXX Packet_stream_tx::Channel<>


XML processing
==============

XML parsing
~~~~~~~~~~~

; XXX Genode::Xml_attribute
;[raw spec/classes/genode/xml_attribute/description]

; XXX Genode::Xml_node
;[raw spec/classes/genode/xml_node/description]


XML generation
~~~~~~~~~~~~~~

; XXX Genode::Xml_generator
;[raw spec/classes/genode/xml_generator/description]


Component management
====================

; Should be preserved for internal use
;Low-level component creation
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~
;
;The 'Process' class provides a convenient front end for the procedure
;described in Section [Component creation].
;
;; Genode::Elf_binary
;; Genode::Elf_segment
;; Genode::Process


Shared objects
~~~~~~~~~~~~~~

; Genode::Shared_object
[raw spec/classes/genode/shared_object/description]

; Genode::Address_info
[raw spec/classes/genode/address_info/description]


[raw spec/clearpage]

Child management
~~~~~~~~~~~~~~~~

For components that manage a number of child components, each child
is represented by an instance of the 'Child' class.
This instance contains the policy to be applied to the child (for
example how session requests are routed to services)
and contains the child's execution environment including the
RAM session holding the child's memory quota.

; Genode::Child_policy
[raw spec/classes/genode/child_policy/description]

; Genode::Child
[raw spec/classes/genode/child/description]

; XXX Genode::Slave_policy
; XXX Genode::Slave


[raw spec/clearpage]

Session routing
~~~~~~~~~~~~~~~

The service classes support the management of services
announced by children or provided locally, and the synchronization
of service requests with service announcements.

; XXX we may go into more detail - or leave this stuff out?

; XXX Genode::Client
; XXX Genode::Server
; XXX Genode::Service
; XXX Genode::Local_service
; XXX Genode::Parent_service
; XXX Genode::Child_service
; XXX Genode::Service_registry


Session policing
~~~~~~~~~~~~~~~~

; Genode::Child_policy_dynamic_rom_file
; XXX Init::Child_policy_ram_phys
; XXX Init::Child_policy_enforce_labeling
; XXX Init::Child_policy_pd_args
; XXX Init::Child_policy_handle_cpu_priorities
; XXX Init::Child_policy_provide_rom_file
; XXX Init::Child_policy_redirect_rom_file
; XXX Init::Child_config

;; init-specific child implementation is not part of the Genode API
; XXX Init::Child
; XXX Init::Routed_service
; XXX Init::Name_registry


;XXX
;Server API
;==========
;
; Server::Entrypoint


Utilities for user-level device drivers
=======================================

To avoid common implementation bugs in device drivers,
the framework facilitates the declaration of hardware register and bit
layouts in the form of C++ types. By subjecting the device driver's
interaction with the hardware to the to C++ type
system, the consistency of register accesses with the hardware specifications
can be maintained automatically.
Such hardware specifications are declarative and can be cleanly
separated from the program logic of the driver.
The actual driver program is relieved from any intrinsics in the form of
bit-masking operations.

The MMIO access utilities comes in the form of two header files located at
_util/register.h_ and _util/mmio.h_.


Register declarations
~~~~~~~~~~~~~~~~~~~~~

The class templates found in _util/register.h_ provide a means to express
register layouts using C++ types. In a way, these templates make up for
C++'s missing facility to define accurate bitfields.
The following example uses the 'Register' class template to define
a register as well as a bitfield within the register:

! struct Vaporizer : Register<16>
! {
!   struct Enable : Bitfield<2,1> { };
!   struct State  : Bitfield<3,3> {
!     enum{ SOLID = 1, LIQUID = 2, GASSY = 3 };
!   };
!
!   static void     write (access_t value);
!   static access_t read  ();
! };

In the example, 'Vaporizer' is a 16-bit register, which is expressed via the
'Register' template argument. The 'Register' class template allows for
accessing register content at a finer granularity than the whole register
width. To give a specific part of the register a name, the 'Register::Bitfield'
class template is used. It describes a bit region within the range of the
compound register. The bit 2 corresponds to true if the device is enabled and
bits 3 to 5 encode the 'State'. To access the actual register, the methods
'read()' and 'write()' must be provided as back end, which performs the access
of the whole register. Once defined, the 'Vaporizer' offers a handy way to
access the individual parts of the register, for example:

! /* read the whole register content */
! Vaporizer::access_t r = Vaporizer::read();
!
! /* clear a bit field */
! Vaporizer::Enable::clear(r);
!
! /* read a bit field value */
! unsigned old_state = Vaporizer::State::get(r);
!
! /* assign new bit field value */
! Vaporizer::State::set(r, Vaporizer::State::LIQUID);
!
! /* write whole register */
! Vaporizer::write(r);


Memory-mapped I/O
~~~~~~~~~~~~~~~~~

The utilities provided by _util/mmio.h_ use the 'Register' template class as
a building block to provide easy-to-use access to memory-mapped I/O registers.
The 'Mmio' class represents a memory-mapped I/O region taking its local base
address as constructor argument. The following example illustrates its use:

! class Timer : Mmio
! {
!   struct Value   : Register<0x0, 32> { };
!   struct Control : Register<0x4, 8> {
!     struct Enable  : Bitfield<0,1> { };
!     struct Irq     : Bitfield<3,1> { };
!     struct Method  : Bitfield<1,2>
!     {
!       enum { ONCE = 1, RELOAD = 2, CYCLE = 3 };
!     };
!   };
!
!   public:
!
!     Timer(addr_t base) : Mmio(base) { }
!
!     void enable();
!     void set_timeout(Value::access_t duration);
!     bool irq_raised();
! };

The memory-mapped timer device consists of two registers: The 32-bit 'Value'
register and the 8-bit 'Control' register. They are located at the MMIO offsets
0x0 and 0x4, respectively. Some parts of the 'Control' register have specific
meanings as expressed by the 'Bitfield' definitions within the 'Control'
struct.

Using these declarations, accessing the individual bits becomes almost a
verbatim description of how the device is used. For example:

! void enable()
! {
!   /* access an individual bitfield */
!   write<Control::Enable>(true);
! }
!
! void set_timeout(Value::access_t duration)
! {
!   /* write complete content of a register */
!   write<Value>(duration);
!
!   /* write all bitfields as one transaction */
!   write<Control>(Control::Enable::bits(1) |
!                  Control::Method::bits(Control::Method::ONCE) |
!                  Control::Irq::bits(0));
! }
!
! bool irq_raised()
! {
!   return read<Control::Irq>();
! }

; XXX describe w/o the generated class descriptions
;; Genode::Register<>
;[raw spec/classes/genode/register/description]
;
;; Genode::Bitset_2<>
;[raw spec/classes/genode/bitset_2/description]
;
;; Genode::Bitset_3<>
;[raw spec/classes/genode/bitset_3/description]
;
;; Genode::Mmio
;[raw spec/classes/genode/mmio/description]

; XXX Genode::Attached_mmio


;;;; Out of scope
; Genode::Texture_base
; Genode::Path_base
; Genode::Surface_base
; Genode::Texture<>
; Genode::Path<>
; Genode::Pixel_rgba<>
; Genode::Surface<>
; Component-local VFS
